fix(kubernetes): keep a late stop snapshot from reviving a stopped sandbox - #5196

TL;DR

Problem: On Kubernetes, stopping a sandbox could make it look like it was starting again. The driver marks a sandbox with the same "operation in progress" flag during a start and during a stop, and it reported every flagged sandbox to the gateway as starting. A status update from the middle of a stop can arrive late, after the gateway has already marked the sandbox Stopped. The gateway took that late update as a sign that a start had begun, moved the sandbox back to Provisioning, and then rejected the next stop.

Fix: The driver now checks which operation set the flag. During a stop, it still reports the sandbox as not ready, but it no longer says a start is underway, so a late update can't bring back a stopped sandbox. Starts and restarts are reported as before.

Summary

On Kubernetes, a stopped sandbox could flip back to Provisioning with no start, and the next stop was then rejected. This happened when the driver delivered a snapshot taken during the stop after the stop had already settled. The driver now stops labelling stop-time snapshots as a starting generation.

Related Issue

Closes #5195

Changes

• openshell-driver-kubernetes: the watch and get converter now checks which operation set the sandbox-runtime bootstrap annotations. For a stop (bootstrap-operation: "stop"), it still withdraws readiness and still holds back Suspended until the stop's completion patch, but it no longer adds Bootstrapping=True. Create, restart and annotations without an operation keep the existing marking. The marking moved into a small synchronous helper, sandbox_from_object_with_bootstrap_state, so it can be unit tested without a Kubernetes client.
• Driver regression tests:
  • A mid-stop CR reports neither Bootstrapping=True nor Suspended=True, and isn't Ready. This fails on main.
  • Mid-create, mid-restart and no-operation CRs still report Bootstrapping=True.
• Gateway contract test kubernetes_stop_snapshots_settle_without_reviving_the_sandbox: walks a stop through a stop-time snapshot (stays Stopping, never Provisioning or Error), the completed stop (Stopped), and a late replay of the stop-time snapshot (stays Stopped), with and without a connected supervisor session. It passes on main; the driver test covers the regression.

Why fix the driver and not add a gateway guard:

• The gateway documents Bootstrapping=True as authoritative evidence of an accepted start. active_bootstrap_snapshot_recovers_stale_stopped_view relies on that to move a Stopped view the gateway didn't know was stale.
• A guard keyed on a gateway-side in-flight start would break that recovery, because recovery exists for when the gateway's view lags.
• With only the condition, the gateway can't tell a stop-time snapshot from a start-time one.
• The driver was the side breaking the contract (the gateway code comment says "a genuine stop includes Suspended=True"). Fixing the driver leaves the start path unchanged.
• That's also why the new gateway test passes on main: it pins the gateway's half of the contract for the snapshot shape the driver now emits.

Testing

• Checks appropriate to the affected code and behavior pass:
  • cargo fmt --all -- --check
  • cargo clippy --locked -p openshell-driver-kubernetes -p openshell-server --all-targets -- -D warnings
  • cargo nextest run -p openshell-driver-kubernetes: 332 passed
  • cargo nextest run -p openshell-server: 2666 passed, 38 skipped (PostgreSQL-backed)
• Unit tests added/updated: stop_snapshot_does_not_report_a_starting_generation failed before the fix and passes after it.
• E2E tests added/updated (if applicable): no new E2E test, since the race is timing dependent. The Kubernetes lanes run conformance lifecycle::restart_stopped_sandbox, which is where it was seen.

Checklist

• Follows Conventional Commits
• Commits are signed off (DCO)
• Architecture docs updated (if applicable): not applicable